home *** CD-ROM | disk | FTP | other *** search
/ Freaks Macintosh Archive / Freaks Macintosh Archive.bin / Freaks Macintosh Archives / Textfiles / Hacking / TCP-IPtweak.txt.sit / TCP-IPtweak.txt next >
Internet Message Format  |  1997-09-25  |  11KB
  1. From: emv@tubed.com (Edward Vielmetti)
  2. Date: Sun Jan 29 20:36:13 EST 1995
  3. Subject: A Weakness in the 4.2BSD Unix (tm) TCP/IP Software
  4.  
  5. This is an incomplete transcription of the Postscript
  6. version of the paper.  Please refer to the original document for
  7. all figures and to get a complete copy.
  8.  
  9. --Ed
  10.  
  11. -----------------------------------------------------------------
  12.  
  13. A Weakness in the 4.2BSD Unix (tm) TCP/IP Software
  14.  
  15. Robert T. Morris
  16.  
  17. AT&T Bell Laboratories
  18. Murray Hill, New Jersey 07974
  19.  
  20. ABSTRACT
  21.  
  22. The 4.2 Berkeley Software Distribution of the Unix operating system
  23. (4.2BSD for short) features an extensive body of software based on the
  24. "TCP/IP" family of protocols.  In particular, each 4.2BSD system "trusts"
  25. some set of other systems, allowing users logged into trusted systems
  26. to execute commands via a TCP/IP network without supplying a password.
  27.  
  28. These notes describe how the design of TCP/IP and the 4.2BSD
  29. implementation allow users on untrusted and possibly very distant hosts
  30. to masquerade as users on trusted hosts.
  31.  
  32. Bell Labs has a growing TCP/IP network connecting machines with
  33. varying security needs; perhaps steps should be taken to reduce their
  34. vulnerability to each other.
  35.  
  36. February 25, 1985
  37.  
  38. Unix is a Trademark of AT&T Bell Laboratories.
  39.  
  40. -----
  41.  
  42. A Weakness in the 4.2BSD Unix TCP/IP Software
  43.  
  44. Robert T. Morris
  45.  
  46. AT&T Bell Laboratories
  47. Murray Hill, New Jersey 07974
  48.  
  49. The Defense Department "TCP/IP" network protocol standard was designed
  50. in 1979 to implement an "internet": a group of networks, highly variable
  51. in reliability and speed, connected by computers acting as gateways.
  52. One of the more popular Unix TCP/IP implementations comes with the 4.2BSD 
  53. system, used both within Bell Labs and on Defense Department networks.
  54.  
  55. 4.2BSD Unix TCP/IP software is very flexible and convenient, but places
  56. too much trust in a protocol which provides very little security.
  57. The attack described here requires no modifications to the system it
  58. runs on, and is not dependant on the hardware of the network involved.
  59.  
  60. TCP/IP conceptually divides into two layers, a "Transmission Control
  61. Protocol" and an "Internet Protocol". The IP layer sends packets of
  62. data ("datagrams") from one host to another, via networks and gateways
  63. interconnecting them.
  64.  
  65. The TCP supports a number of "ports" on each host running IP, providing
  66. reliable and flow controlled "virtual circuits" between these ports;
  67. TCP circuits are built on top of the IP datagram service. Each TCP or
  68. IP packet consists of a header full of control information followed by
  69. data; in the case of TCP the data is supplied by the user, while the
  70. data in an IP packet is a TCP packet.
  71.  
  72. The important parts of the TCP header are a source port number, a
  73. destination port number, a sequence number, an acknowledgement number, and
  74. some flags.  The port numbers identify which virtual circuit is involved,
  75. the sequence and acknowledgement numbers ensure that data is received in
  76. the correct order, and the flags affect the state of the virtual circuit.
  77.  
  78. An IP header consists primarily of source and destination host 
  79. identifiers; these are 32 bit numbers which uniquely indicate
  80. a host and a network.
  81. There is also a protocol number indicating which protocol layer 
  82. (e.g. TCP) IP should direct the packet data to.
  83.  
  84. 4.2BSD provides a remote execution "server", which listens for TCP
  85. connection requests on port 512.  When such a request arrives at a
  86. machine, the server checks that the originating host is "trusted" by
  87. comparing the source host ID in the IP header to a list of trusted
  88. computers.  If the source host is OK, the server reads a user id and a
  89. command to execute from the virtual circuit TCP provides.
  90.  
  91. The weakness in this scheme is that the source host itself fills in
  92. the IP source host id, and there is no provision in 4.2BSD or TCP/IP to
  93. discover the true origin of a packet.
  94.  
  95. The ideal way to produce TCP/IP packets with incorrect source host id's
  96. would be to talk directly to the network involved.
  97.  
  98. 4.2BSD
  99. provides no such network interface, so other means must be sought to
  100. forge.
  101.  
  102. 4.2BSD does allow privileged users to send IP packets, though; with
  103. minimal effort the IP kernel code can be made to supply the correct
  104. protocol number (6), and an incorrect host id, in the IP header.
  105.  
  106.  
  107. The details involve creating a 4.2BSD "socket" with type "SOCK RAW",
  108. and then writing on the kernel data structures to change the protocol
  109. number associated with "SOCK RAW" to that of TCP and to change 
  110. the source host id.
  111.  
  112. This requires privileges; however, it is likely that at least one system
  113. on a large network will be insecure enough to supply appropriate powers
  114. after a determined attack.
  115.  
  116. With appropriate access to IP, a user process can create and 
  117. manage one end of a TCP circuit without using the TCP software in the
  118. Unix kernel.
  119.  
  120. Each TCP header contains a checksum to detect inaccurate
  121. transmission. This checksum covers not only the TCP header and data, but
  122. also some of the the IP header with which the kernel will encapsulate
  123. packets from 4.2BSD systems.  Hence the user software must predict the
  124. contents of IP header.
  125.  
  126.  
  127.  
  128. Unix is a Trademark of AT&T Bell Laboratories.
  129.  
  130. 1. RFC 791, University of Southern California ISI,
  131. Marina del Ray, Cal. 90291
  132. 2. RFC 793, Sept 1981
  133.  
  134. At this stage, a user process can send individual TCP packets.
  135.  
  136.  the TCP packet.
  137.  
  138.  The interesting TCP connection
  139.  states are LISTEN, SYN SENT, SYN RCVD, and ESTABLISHED. Each
  140.  packet flags
  141.  The
  142.  TCP connection also maintains a sequence number as part of its
  143.  state.
  144.  
  145.  number, affect the state.
  146.  
  147.  SYN, ACK, and RST \(synchronize, acknowledge, and reset\
  148.  , as well as the packet acknowledgement
  149.  
  150.  end of a connection starts by sending a SYN and entering SYN
  151.  One
  152.  
  153.  SENT; the other
  154.  
  155.  is represented by a
  156.  the abbreviated state table following, each message
  157.  In
  158.  end starts out in LISTEN state.
  159.  
  160.  Each
  161.  the packet sequence number, the acknowledgement number, and 
  162.  possibly some data.
  163.  packet flag,
  164.  
  165.  possibly an error; each of the
  166.  state/event combination usually leads to a packet being sent, a 
  167.  state change, or
  168.  
  169.  means the sequence number
  170.  M
  171.  to be sent and a state to be entered.
  172.  boxes in the diagram indicates a packet
  173.  
  174.  means the sequence number remembered as part of the state of the TCP port.
  175.  of the packet just received; N
  176.  
  177. For instance, M would refer to the X in the received packet ACK,X,Y.
  178.  
  179. SYN,X,Y ACK,X,Y,data
  180. LISTEN SYN,N++,M+1
  181.  
  182. SYN
  183. RCVD error
  184. SYN
  185. SENT ACK,N,M+1
  186. ESTABLISHED error
  187. SYN
  188. RCVD RST,N,M
  189. error ESTABLISHED
  190.  
  191.  len
  192.  ACK,N,M+data
  193.  ESTABLISHED RST,N,M
  194.  error ESTABLISHED
  195.  send data to user
  196.  
  197.  
  198.  both sides of the connection are in the ESTABLISHED state, after
  199.  Data is sent by ACK,N,M,data when
  200.  
  201.  are also other states and flags having to do with
  202.  There
  203.  the length of the data.
  204.  which N is incremented by
  205.  
  206.  closing connections which are not relevant here.
  207.  
  208.  4.2BSD maintains a global initial sequence number, which is incremented
  209.  by 128 each second and by
  210.  
  211.  a SYN packet
  212.  
  213.  When
  214.  
  215.  after each connection is started; each new connection starts off with 
  216.  this number.
  217.  
  218.  packet will
  219.  
  220.  a host, the destination host will send the reply to the presumed source
  221.  with a forged source is sent from
  222.  host, not the forging host.
  223.  
  224. The forging host must discover or guess what the sequence
  225. number in that lost
  226. packet was, in order to acknowledge it and put the destination TCP 
  227. port in the ESTABLISHED state.
  228.  
  229.  
  230. Guessing the lost sequence
  231. number is easy when the destination runs 4.2BSD; one need only create a real
  232. connection, look in the kernel for the sequence number received, and 
  233. add 64 to it.
  234.  
  235. Once the forging program acknowledges this sequence number, the
  236. connection is fully set up and data may be sent, though not
  237. received, by the program.
  238.  
  239. Unfortunately, the SYN packet sent by the destination to the 
  240. putative source does not just disappear.
  241.  
  242. The supposed source sees it as a packet on
  243. a non-existent circuit, and sends a packet with a RST flag to the
  244. destination. This causes the destination to
  245. throw away the forged circuit.
  246. For instance: Host A sends a forged packet to B, claiming
  247. the source was C.  B sends a SYN packet to C, and C sends a RST packet to
  248. B. B throws away the circuit that A is forging to it.
  249.  
  250. The only ports on C that won't always generate RSTs
  251. in this situation are those which are waiting, or listening, for connections.
  252.  
  253. Those listening ports have finite length queues
  254. of connections waiting to be set up; if this queue length is exceeded, 
  255. the requesting SYN be thrown away, but no reset will be generated.
  256.  
  257. The originator is expected to resend the SYN packet after timing out.
  258.  
  259. Note
  260. that original SYN packets and response SYN packets
  261. look the same.
  262.  
  263. Thus it suffices for the forging process to claim that the packets
  264. are coming from a port on the supposed source that
  265. has a server listening for connections, and for the forger to flood that 
  266. port with connection requests.
  267.  
  268. In summary, suppose the forging program is named A, its destination host is
  269. named B, the source to be forged is named C.
  270.  
  271. The port on B involved
  272. is number 514, the remote execution server's port; A will
  273. forge packets from port 21 on host C, which is usually waiting for 
  274. connections.
  275.  
  276. The chain of events on A is as follows:
  277.  
  278. Swamp port 21 on C with connection requests.
  279.  
  280. Create a real connection to a port on B, and record the
  281. sequence number returned by B.
  282.  
  283. Create a raw IP socket, change its protocol to that of TCP,
  284. and change its source to C (by writing in the kernel) .
  285.  
  286. Send a SYN packet from port 21 (supposedly on C) to port 514 on B.
  287. A then sends a SYN to port 21 on C, which is silently ignored because
  288. C's queue for 21 is full.
  289.  
  290. Send an ACK packet to B with the acknowledgement number equal to the
  291. sequence number previously recorded plus 64.
  292.  
  293. Send data to B, taking care to increment the sequence number each time
  294. by the amount of data sent. Port 514 expects a null, followed by a user
  295. name, followed by a command.  If all goes well, and B trusts C, B will
  296. execute the command.
  297.  
  298. Accuracy has been sacrificed for clarity, such as it is.
  299.  
  300. This scheme, with the details filled in, does in fact work fairly
  301. reliably.  It allows machines on a TCP/IP network to run commands on
  302. any connected 4.2BSD system that "trusts" any other system.
  303.  
  304. There are a number of possible defences.  The sequence numbers that
  305. the forger must guess could be made very random; they are in a 32 bit
  306. word, so brute force search is unprofitable.  However, the forger can
  307. ask for an arbitrarily large number of test connections to determine
  308. regularities in the random number algorithm; at best randomness will
  309. make the forger's job somewhat harder.
  310.  
  311. A better approach might be to require that all networks IP uses supply
  312. genuine source host id's.  This is network hardware dependent, and in
  313. any case will not work if gateways are involved.  A workable solution
  314. might be to only trust hosts on the same physical network, and modify
  315. gateways to reject packets that claim to, but do not in fact, come from
  316. directly connected networks.
  317.  
  318. February 25, 1985
  319.